 
  

 






<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 
<html>

<!-- Mirrored from www.javapractices.com/topic/TopicAction.do?Id=205 by HTTrack Website Copier/3.x [XR&CO'2010], Sun, 12 Jun 2011 17:28:08 GMT -->
<!-- Added by HTTrack --><meta http-equiv="content-type" content="text/html;charset=UTF-8"><!-- /Added by HTTrack -->
<head>
 <title>
  Java Practices -> Package by feature, not layer
 </title>
 <link rel="stylesheet" type="text/css" href="../stylesheet8.css" media="all">
 
 <link rel="shortcut icon" href='../images/favicon.ico' type="image/vnd.microsoft.icon">
 <meta name="description" content="Concise presentations of java programming practices, tasks, and conventions, amply illustrated with syntax highlighted code examples.">
 
 <meta name='keywords' content='java,java programming,java practices,java idiom,java style,java design patterns,java coding conventions,'>
 
 
</head>
 
<body>


<div class='menu-bar'>
 
  <a href='../home/HomeAction.html' title='Table of Contents'>Home</a> |
  <a href='../vote/VoteSummaryAction-2.html' title='View Poll Results'>Poll</a> |
   
  <A href='../feedback/FeedbackAction451f-2.html?Operation=Show' title='Send Your Feedback'>Wiki</a> |
  <b><a href='../source/SourceAction-2.html' title='Grab Source Code'>Source Code</a></b><IMG class='no-margin' SRC="../images/goldstar.gif" ALT=""> |

  <a href='http://www.web4j.com/Java_Web_Application_Framework_Overview.jsp?From=1' title='Free Download - Java Web Application Framework'><b>WEB4J</b></a> |
  
  <a href='http://www.date4j.net/' title='Replacement for java.util.Date'><b>DATE4J</b></a> |

   <a href='../references/ReferencesAction-2.html' title='References'>Links</a>
   
  <form action='http://www.javapractices.com/search/SearchAction.do' method='get' class='search-form'>
   <input type='text' name='SearchTerms' value="" size=12 maxlength=50 class='search'>
   <input type='submit' value="Search">
  </form>
 
</div>

<P>



  

 






<p class="display-messages">

 

 

</p>


<div class="main-layout">
 
   

 




<div class='page-title'>Package by feature, not layer</div>

<div class='main-body'>
 
<br>The first question in building an application is <em>"How do I divide it up into packages?"</em>. 
For <em>typical business applications</em>, there seems to be two ways of answering this question.

<h3>Package By Feature</h3>
<i>Package-by-feature</i> uses packages to reflect the feature set. 
It places all items related to a single feature (and <em>only</em> that feature) into a single directory/package. 
This results in packages with high cohesion and high modularity, with minimal coupling between packages.
Items that work closely together are placed next to each other. 
They aren't spread out all over the application.
It's also interesting to note that, <em>in some cases</em>, deleting a feature can reduce to a single operation - deleting a directory.
(Deletion operations might be thought of as a good test for maximum modularity: an item has maximum modularity only if it can be deleted in a single operation.)

<P>In package-by-feature, the package names correspond to important, high-level aspects of the problem domain. 
For example, a drug prescription application might have these packages :
<ul>
<li><tt>com.app.doctor</tt></li>
<li><tt>com.app.drug</tt></li>
<li><tt>com.app.patient</tt></li>
<li><tt>com.app.presription</tt></li>
<li><tt>com.app.report</tt></li>
<li><tt>com.app.security</tt></li>
<li><tt>com.app.webmaster</tt></li>
<li><tt>com.app.util</tt></li>
<li>and so on...</li>
</ul>

Within each package are all (or most) items related to that particular feature (and only that feature).
For example, the <tt>com.app.doctor</tt> package might contain these items :
<ul>
 <li><tt>DoctorAction.java</tt> - an action or controller object
 <li><tt>Doctor.java</tt> - a Model Object
 <li><tt>DoctorDAO.java</tt> - Data Access Object
 <li>database items
 <li>user interface items (perhaps a JSP, in the case of a web app)
</ul>

<P>It's important to note that a package can contain not just Java code, but other files as well.
Indeed, in order for package-by-feature to really work as desired, <em>all</em> items related to a 
given feature - from user interface, to Java code, to database items - must be placed in a single directory dedicated to that feature (and <em>only</em> that feature).

<P><em>In some cases</em>, a feature/package will not be used by any other feature in the application.
If that's the case, it may be removed simply by deleting the directory.
If it is indeed used by some other feature, then its removal will not be as simple as a single delete operation.

<P>That is, the package-by-feature idea does not imply that one package can never use items belonging to other packages.
Rather, package-by-feature prefers package-private as the default scope, and increases the scope of an item to public only when needed. 

<h3>Package By Layer</h3>
The competing <i>package-by-layer</i> style is different. 
In package-by-layer, the highest level packages reflect the various application "layers", instead of features, as in :
<ul>
<li><tt>com.app.action</tt></li>
<li><tt>com.app.model</tt></li>
<li><tt>com.app.dao</tt></li>
<li><tt>com.app.util</tt></li>
</ul>

Here, each feature has its implementation spread out over multiple directories, over what might be loosely called "implementation categories".
Each directory contains items that usually aren't closely related to each other. 
This results in packages with low cohesion and low modularity, with high coupling between packages.
As a result, editing a feature involves editing files across different directories. 
In addition, deleting a feature can almost never be performed in a single operation.


<h3>Recommendation : Use Package By Feature</h3>

<em>For typical business applications</em>, the package-by-feature style seems to be the superior of the two :

<p><b>Higher Modularity</b>
<br>As mentioned above, only package-by-feature has packages with high cohesion, high modularity, and low coupling between packages.

<p><b>Easier Code Navigation</b>
<br>Maintenance programmers need to do a lot less searching for items,
since all items needed for a given task are usually in the same directory.
Some tools that encourage package-by-layer use package naming conventions to ease the problem of tedious code navigation.
However, package-by-feature <em>transcends the need for such conventions in the first place</em>, by greatly reducing the need to navigate between directories.

<p><b>Higher Level of Abstraction</b>
<br>Staying at a high level of abstraction is one of programming's guiding
principles of lasting value. It makes it easier to think about a problem,
and emphasizes fundamental services over implementation details. As a direct
benefit of being at a high level of abstraction, the application becomes
more self-documenting : the overall size of the application is communicated
by the number of packages, and the basic features are communicated by the
package names. <span class='highlight'>The fundamental flaw with package-by-<em>layer</em> style,
on the other hand, is that it puts implementation details ahead of high level abstractions - which is backwards.</span>

<p><b>Separates Both Features <i>and</i> Layers</b>
<br>The package-by-feature style still honors the idea of separating layers,
but that separation is implemented using separate <em>classes</em>. The package-by-<em>layer</em>
style, on the other hand, implements that separation using <i>both</i>
separate classes <i>and</i> separate packages, which does not seem necessary
or desirable.

<p><b>Minimizes Scope</b>
<br>Minimizing scope is another guiding principle of lasting value. Here,
package-by-feature allows some classes to decrease their scope from public to
package-private. This is a significant change, and will help to
<a href='TopicAction23a3-2.html'>minimize ripple effects</a>.
The package-by-layer style, on the other hand, effectively abandons package-private scope, 
and forces you to implement nearly all items as <tt>public</tt>. 
This is a fundamental flaw, since it doesn't allow you 
to minimize ripple effects by keeping secrets.

<p><b>Better Growth Style</b><br>
In the package-by-feature style, the number of classes within each package remains
limited to the items related to a specific feature. If a package becomes
too large, it may be refactored in a natural way into two or more packages.
The package-by-<em>layer</em> style, on the other hand, is monolithic. As an application grows in
size, the number of packages remains roughly the same, while the number
of classes in each package will increase without bound. 

<hr width="30%">

<P>If you still need further convincing, consider the following.

<p><b>Directory Structure Is Fundamental To Your Code</b>

<P><span class='highlight'>"As any designer will tell you, it is the first steps in a design process which count for most. 
The first few strokes, which create the form, carry within them the destiny of the rest."</span> - <em>Christopher Alexander</em>

<P>(Christopher Alexander is an architect. Without having worked as programmer, he has influenced many people who think 
a lot about programming. His early book <em>A Pattern Language</em> was the original inspiration for the 
Design Patterns movement. He has thought long and hard about how to build beautiful things, and these reflections 
seem to largely apply to software construction as well.)

<P>In a CBC radio interview, Alexander recounted the following story (paraphrased here):
"I was working with one of my students. He was having a very difficult time building something. He just didn't know 
how to proceed at all. So I sat with him, and I said this: Listen, start out by figuring out what the most important 
thing is. Get that straight first. Get that straight in your mind. Take your time. Don't be too hasty. Think 
about it for a while. When you feel that you have found it, when there is no doubt in your mind that it is 
<em>indeed</em> the most important thing, then go ahead and 
make that most important thing. When you have made that most important thing, ask yourself if you can make it more 
beautiful. Cut the bullshit, just get it straight in your head, if you can make it better or not. When that's done, 
and you feel you cannot make it any better, then find the <em>next</em> most important thing."

<P>
What are the first strokes in an application, which create its overall form? 
It is the directory structure. <span class='highlight'>The directory structure 
is the very first thing encountered by a programmer when browsing source code. 
Everything flows from it. 
Everything depends on it.
</span> 
It is clearly one of the most important aspects of your source code.

<P>Consider the different reactions of a programmer when encountering different directory structures.
For the package-by-feature style, the thoughts of the application programmer might be like this :
<ul>
<li>"I see. This lists all the top-level features of the app in one go. Nice."
<li>"Let's see. I wonder where this item is located....Oh, here it is. And everything else I am going to 
need is right here too, all in the same spot. Excellent."
</ul>

For the package-by-<em>layer</em> style, however, the thoughts of the application programmer might be more like this :
<ul>
<li>"These directories tell me nothing. How many features in this app? Beats me. It looks exactly the same as 
all the others. No difference at all. Great. Here we go again..."
<li>"Hmm. I wonder where this item is located....I guess its parts are all over the app, spread around in all these 
directories. Do I really have all the items I need? I guess we'll find out later."
<li>"I wonder if that naming convention is still being followed. If not, I will have to look it up in that other directory."
<li>"Wow, would you look at the size of this single directory...sheesh."
</ul>

<p><b>Package-By-Layer in Other Domains is Ineffective</b>
<P>
By analogy, one can see that the package-by-layer style leads to poor results.
For example, imagine a car. At the highest level, a car's 'implementation' is divided this way (package-by-feature) :
<ul>
<li>safety
<li>engine
<li>steering
<li>fuel system
<li>and so on...
</ul>

<P>Now imagine a car whose 'implementation' under the hood is <em>first</em> divided up according to these 
lower level categories (package-by-layer) :
<ul>
<li>electrical
<li>mechanical
<li>hydraulic
</ul>

In the case of a transmission problem, for example, you might need to tinker around in these three compartments. 
This would mean moving from one part of the car to another completely different one. 
While in these various compartments, you could 'see' items having absolutely nothing to do with problem you are 
trying to solve. They would simply be in the way, always and everywhere distracting you from the real task at hand. 
Wouldn't it make more sense if there was a single place having exactly what you need, and nothing else?

<P>As a second example, consider a large bureacracy divided up into various departments (package-by-feature):
<ul>
<li>front office
<li>back office
<li>accounting
<li>personnel
<li>mail room
</ul>

If a package-by-layer style was used, the primary division would be something like :
<ul>
<li>executives
<li>managers
<li>employees
</ul>

Now imagine the bureacracy being divided <em>physically</em> according to these three categories. Each manager is 
located, for example, with all the other managers, and not with the employees working for them. 
Would that be effective? No, it wouldn't.

<P>So why should software be any different? It seems that package-by-layer is just a bad habit waiting to be broken.

<P>The example application that comes with <a href="TopicAction5f31-2.html?Id=188">WEB4J</a> uses the package-by-feature style.

<br>
<br>

</div>




<div class='topic-section'>See Also :</div>
<div class='main-body'>
 
  
  <a href='TopicAction42fc-2.html?Id=112'>JSPs should contain only presentation logic</a> <br>
 
  
  <a href='TopicAction5f31-2.html?Id=188'>A Web App Framework - WEB4J</a> <br>
 
</div>


<div class='topic-section'>Would you use this technique?</div>
<div class='main-body'>
  
  <form action="http://www.javapractices.com/vote/AddVoteAction.do" method='post'>
    Yes<input type='radio' name='Choice' value='Y' >
    &nbsp;&nbsp;No<input type='radio' name='Choice' value='N'>
    &nbsp;&nbsp;Undecided<input type='radio' name='Choice' value="?" >
    &nbsp;&nbsp;<input type=submit value="Vote" >
    <input type='hidden' name='Operation' value='Apply'>
    <input type='hidden' name='TopicId' value='205'>
  </form>
</div>

<div style='height:10.0em;'></div>

 
 
</div>

  

 





<div align='center' class='legalese'>  
&copy; 2011 Hirondelle Systems |
<a href='../source/SourceAction-2.html'><b>Source Code</b></a><IMG class='no-margin' SRC="../images/goldstar.gif" ALT=""> |
<a href="mailto:webmaster@javapractices.com">Contact</a> |
<a href="http://creativecommons.org/licenses/by-nc-sa/1.0/">License</a> |
<a href='../apps/cjp.rss'>RSS</a>
<!-- ukey="2AC36CD2" -->
<!-- ckey="16DF3D87" -->
<br>

 Individual code snippets can be used under this <a href='../LICENSE.txt'>BSD license</a> - Last updated on June 6, 2010.<br>
 Over 150,000 unique IPs last month - <span title='Java Practices 2.6.5, Mon May 16 00:00:00 EDT 2011'>Built with</span> <a href='http://www.web4j.com/'>WEB4J</a>.<br>
 - In Memoriam : Bill Dirani -
</div>

<script src="../../www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-2633428-1";
urchinTracker();
</script>



</body>

<!-- Mirrored from www.javapractices.com/topic/TopicAction.do?Id=205 by HTTrack Website Copier/3.x [XR&CO'2010], Sun, 12 Jun 2011 17:28:08 GMT -->
<!-- Added by HTTrack --><meta http-equiv="content-type" content="text/html;charset=UTF-8"><!-- /Added by HTTrack -->
</html>
